Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.

...powered by www.netzwerkartist.de...

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Sprachbeschreibung
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Mathematisches
6 Eigene Klassen schreiben
7 Exceptions
8 Die Funktionsbibliothek
9 Threads und nebenläufige Programmierung
10 Raum und Zeit
11 Datenstrukturen und Algorithmen
12 Dateien und Datenströme
13 Die eXtensible Markup Language (XML)
14 Grafische Oberflächen mit Swing
15 Grafikprogrammierung
16 Das Netz
17 JavaServer Pages und Servlets
18 Verteilte Programmierung mit RMI und Web–Services
19 Applets, Midlets und Sound
20 Datenbankmanagement mit JDBC
21 Reflection und Annotationen
22 Komponenten durch Bohnen
23 Logging und Monitoring
24 Sicherheitskonzepte
25 Java Native Interface (JNI)
26 Dienstprogramme für die Java-Umgebung
A Die Begleit-DVD
Index

Download:
- ZIP, ca. 12,5 MB
Buch bestellen

Website zum Buch
Weblog des Autors
Ihre Meinung?

Spacer
 <<   zurück
Java ist auch eine Insel von Christian Ullenboom
Programmieren mit der Java Standard Edition Version 6
Buch: Java ist auch eine Insel

Java ist auch eine Insel
6., akt. und erw. Aufl., mit DVD
1.454 S., 49,90 Euro
Galileo Computing
ISBN 3-89842-838-9
gp 18 Verteilte Programmierung mit RMI und Web–Services
  gp 18.1 Entfernte Objekte und Methoden
    gp 18.1.1 Stellvertreter helfen bei entfernten Methodenaufrufen
    gp 18.1.2 Standards für entfernte Objekte
  gp 18.2 Java Remote Method Invocation
    gp 18.2.1 Zusammenspiel von Server, Registry und Client
    gp 18.2.2 Wie die Stellvertreter die Daten übertragen
    gp 18.2.3 Probleme mit entfernten Methoden
    gp 18.2.4 Nutzen von RMI bei Middleware-Lösungen
    gp 18.2.5 Zentrale Klassen und Schnittstellen
    gp 18.2.6 Entfernte und lokale Objekte im Vergleich
  gp 18.3 Auf der Serverseite
    gp 18.3.1 Entfernte Schnittstelle deklarieren
    gp 18.3.2 Remote-Objekt-Implementierung
    gp 18.3.3 Stellvertreterobjekte erzeugen
    gp 18.3.4 Der Namensdienst (Registry)
    gp 18.3.5 Remote-Objekt-Implementierung exportieren und beim Namensdienst anmelden
    gp 18.3.6 Einfaches Logging
    gp 18.3.7 Aufräumen mit dem DGC
  gp 18.4 Auf der Clientseite
  gp 18.5 Entfernte Objekte übergeben und laden
    gp 18.5.1 Klassen vom RMI-Klassenlader nachladen
  gp 18.6 Der Server startet die Registry selbst
  gp 18.7 Weitere Eigenschaften von RMI
    gp 18.7.1 RMI und CORBA
    gp 18.7.2 RMI über HTTP getunnelt
    gp 18.7.3 Automatische Remote-Objekt-Aktivierung
  gp 18.8 Daily Soap
    gp 18.8.1 SOAP-Protokoll
    gp 18.8.2 Die technische Realisierung
    gp 18.8.3 SOAP-Implementierungen
    gp 18.8.4 @WebService in Java 6
    gp 18.8.5 Einen Web-Service definieren
    gp 18.8.6 Web-Services veröffentlichen
    gp 18.8.7 Einen JAX-WS-Client implementieren
  gp 18.9 Java Message Service (JMS)
  gp 18.10 Zum Weiterlesen


Galileo Computing

18.5 Entfernte Objekte übergeben und laden  downtop

In unserem bisherigen Beispiel haben wir zwei Ganzzahlwerte übergeben. Die Implementierung der Stellvertreter ist nun so, dass eine Socket-Verbindung die Daten überträgt. Da keine Objekte transportiert werden, muss keine Objekt-Serialisierung die Daten übertragen. Wir wollen uns nun damit beschäftigen, was mit Objekten passiert, die übertragen werden. Wir können verschiedene Klassen unterscheiden:

  • Klassen, die auf beiden Seiten vorliegen, weil es zum Beispiel Klassen aus dem Standard-API sind
  • Klassen, die nur auf der Serverseite vorliegen und dem Client nicht bekannt sind
  • Klassen, die selbst wieder Remote implementieren

Falls die Klasse auf beiden Seiten als Klassenbeschreibung vorliegt, weil es sich etwa um eine Standardklasse handelt, oder ist sie in beiden Pfaden eingetragen, sind keine Probleme zu erwarten. Die übertragenen Daten müssen jedoch von Klassen stammen, die serialisierbar sind.

Wann ist eine Klassenbeschreibung nötig?

Schwierig wird die Lage erst, wenn der Server Klassen benötigt, die beim Client liegen. Es könnte etwa eine entfernte Methode

int max( List v );

geben, die das Maximum der Elemente aus der Sammlung bildet. Die Elemente sind jedoch Objekte, die der Server vorher nicht gesehen hat, etwa Objekte vom Typ Schutzpatron.


Galileo Computing

18.5.1 Klassen vom RMI-Klassenlader nachladen  toptop

Wir kommen also dazu, dass der Klassenlader Klassen nachladen muss, die für den verteilten Aufruf auf der Client- und Serverseite nötig sind. Das erinnert an einen Applet-Klassenlader, der Gleiches machen muss. Für RMI-Aufrufe kommt der RMI-Klassenlader java.rmi.RMIClassLoader zum Zuge. Dieser Lader lädt jetzt die Stellvertreter (die Stubs) sowie weitere benötigte Klassen in die lokale virtuelle Maschine. Woher die Klassen kommen, ist dem Lader egal. Sie können in CLASSPATH stehen, im aktuellen Verzeichnis oder auf einem Webserver. Im letzten Fall steuert die Eigenschaft java.rmi.server.codebase den Ort.


Beispiel Setzen der Codebase auf einen Webserver, damit das RMI-Programm die benötigten Klassen aus http://server/classimlp laden kann:
$ java -Djava.rmi.codebase=http://server/classimlp

Wenn ein Client einen entfernten Aufruf startet, sucht er die Stub-Klasse. Findet er die Klasse nicht in dem eigenen Namensraum, wird die Codebase hinzugezogen. Der Client wird dann die Stub-Klasse von der angegebenen URL anfordern. Der Server überträgt anschließend die Klassendatei zum RMI-Client. Die Stub-Klasse muss dem Server also bekannt sein, da er sie ja übertragen muss.

Sollten die Klassen nur vom Server geladen werden und aus anderen, vielleicht dunklen Stellen des Dateisystems nicht, ist die Eigenschaft java.rmi.useCodebaseOnly auf true zu setzen.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.





 <<   zurück



Copyright © Galileo Press 2007
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de